#6616: createSelectFork does not fork latest block number if you sleep #7087
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
closes #6616
proposed solution for solving #6616, slightly different than suggested #6616 (comment) (in the sense that
url@latest
fork id was made obsolete and insteadurl@latest_block
is recorded)Motivation
Solution
if no block provided then fork is created using latest block for fork id (
url@latest_block
). if block provided then fork id is url@provided_block (this means there'll no longer be aurl@latest
fork id but alwaysurl@block
)after creation of fork the id is checked if in inserted forks. If it doesn't exist then it's inserted, otherwise the existing backend is reused and a new fork
url@latest_block-1
recordedchanged
CreatedFork::inc_senders
to increment number of senders and return the new unique fork id.CreatedFork::num_senders
was removedMultiForkHandler::insert_new_fork
added to handle fork insertion / send on channelsadded Issue6616Test to cover scenario, looping for 50 seconds should suffice with the current average block time of 12